08. 웹 프로토콜 최적화

📝 Contents

HTTP의 발전

  • 초기 HTTP는 버전 정보가 따로 없었지만 이후 구분을 위해 0.9버전이라 이름 붙임
  • HTTP/0.9는 웹 콘텐츠를 요청하는 GET 메소드만 존재하고 HTML만 읽을 수 있을 뿐, 클라이언트의 정보를 서버에 전달할 방법은 없었음
  • 또한 전달 받는 콘텐츠 중 텍스트만 읽을 수 있었지만, HTTP/0.9는 이후 웹을 통해 정보를 전달하는 월드 와이드 웹의 근간이 됨


  • HTTP/1.0 부터는 HTML을 포함하는 HTTP 페이로드 외에도 헤더를 통해 클라이언트와 서버의 정보를 전달할 수 있었음
  • 또한 Content-Type 헤더를 이용해 HTML 뿐만 아니라 이미지나 동영상 등 다양한 정보를 주고받을 수 있게 됨
  • POST 메소드를 추가하여 클라이언트의 정보를 웹 서버로 전달하는 방법도 지원함
  • Content-Encoding 헤더를 통해 클라이언트 서버 간 압축 정보를 공유하며 HTML 등의 스크립트를 압축해 크기를 줄여 전송하고 클라이언트는 이를 압축 해제해 브라우징 함

HTTP/1.1

  • HTTP/1.1은 HTTP의 첫 번째 공식 표준 버전임
  • GET, POST 외에도 PUT과 DELETE를 이용해 파일을 업로드하거나 웹 서버의 내용을 삭제할 방법도 생김
  • Via 헤더를 사용해 중계 서버 정보를 공유하고 Accept 헤더로 클라이언트가 어떤 형식의 콘텐츠를 지원하는지 미리 서버에 알려줄 수 있게 됨
  • 하나의 TCP 연결을 재사용해 많은 콘텐츠를 전달할 수 있는 지속적 연결 기술이 추가됨
  • 브라우저가 웹 서버에 여러 개의 콘텐츠를 요청했을 떄, 이전 요청에 대한 응답을 완전하게 받지 않더라도 지속적 연결로 확보한 하나의 TCP 연결 내에서 미리 다음 요청에 대한 처리를 시작하면서 전체적인 전달 시간을 줄이는 방식인 파이프라이닝 기술이 있음


  • 문제점으로는 클라이언트와 서버가 요청하며 주고받는 통신에는 순서가 있으므로 서버가 하나의 요청에 응답을 지연하면 나머지 모든 요청 역시 지연되는 HOL(Head-Of-Line blocking) 문제가 있음
  • HTTP/2와 HTTP/3은 각각 자체적인 HOL 극복 기술을 선보임

HTTP/2

  • 텍스트 방식의 프로토콜 메시지를 과감히 버리고 이진 포맷을 사용하면서 프로토콜 자체를 경량화하려고 시도함
  • HTTP/2에는 HTTP/1.1의 기능에 멀티플렉싱, 스트림 우선순위 설정, 헤더 압축(HPACK), 서버 푸시 같은 새로운 프로토콜 최적화 기능이 추가됨
  • HTTP/2에서는 HTTP의 HOL 문제를 해결할 수 있었지만 HTTP의 상위 프로토콜인 TCP의 HOL 문제는 해결하지 못함
  • 이 문제를 해결하기 위해 HTTP/3이 개발됨

HTTP/3

  • HTTP/3는 새로운 인터넷 프로토콜인 QUIC을 사용하는 HTTP 최상위 버전
  • QUIC의 가장 큰 특징은 UDP를 사용하다는 점임
  • TCP의 오랜 단점을 TCP 프로토콜 내에서 수정하기는 어렵고, UDP 프로토콜 구조가 최적화를 진행하기 더 쉬운 형태이기 때문에 HTTP/3은 UDP를 사용함
  • 클라이언트와 HTTP/3 서버 사이에 한 번 맺은 QUIC 연결을 최대한 재사용하는 구조이므로 클라이언트와 서버 간 연결을 만드는 과정에서 소모되는 시간이 대폭 줄어듬

HTTP/2의 최적화 기술

  • HTTP/2의 가장 큰 목표는 클라이언트와 서버가 콘텐츠를 주고받는 시간을 줄이고, 서버 응답이 느린 콘텐츠가 다른 정상적인 콘텐츠의 전달을 방해하지 않도록 하는 것
  • 이를 위해 기존 문자열 방식의 프로토콜을 이진 프레임으로 바꾸어 프로토콜을 좀 더 가볍고 유연하게 만듬
  • HTTP 요청과 응답에 포함된 중복 헤더 값들은 걸러내고, 전송해야 하는 값을 기존과 다르게 압축해 헤더의 크기를 최소화함
  • 서버 푸시를 통해 클라이언트가 요청하지 않은 콘텐츠도 서버가 미리 빠르게 전송하여 RTT를 더욱 최소화했음

HTTP/2의 이진 프레임

  • HTTP/2 이전 버전에서 HTTP의 요청과 응답은 메시지라는 단위로 구성됨
  • HTTP의 메시지는 상태 라인, 헤더와 페이로드로 이루어져 요청과 응답에 필요한 정보를 담고 있음
  • HTTP/2에는 기존 HTTP/1.1 버전의 메시지 단위 외에도 프레임, 스트림이라는 단위가 추가됨
    • 프레임: HTTP/2 통신상 제일 작은 정보 단위이며 헤더나 데이터 중 하나임
    • 메시지: HTTP/1.1와 마찬가지로 요청 혹은 응답 단위이며 다수의 프레임으로 이루어짐
    • 스트림: 클라이언트와 서버 사이 맺어진 연결을 통해 양방향으로 주고받는 하나 혹은 복수의 메시지임
  • 여러 개의 프레임이 모여 메시지가 되고 여러 개의 메시지가 모여 스트림이 되는 구조임
  • HTTP/1.0과 HTTP/1.1에서는 요청과 응답이 메시지라는 단위로 완벽하게 구분되어 있었으나 HTTP/2에서는 스트림이라는 단위를 통해 요청과 응답이 하나의 단위로 묶일 수 있는 구조가 만들어짐


  • 큰 데이터는 여러 개의 프레임에 나누어 전달할 수 있고 응답 역시 여러 개의 프레임으로 나누어 전달됨
  • 멀티플렉싱이 적용되어 순서에 상관없이 클라이언트에게 전달됨
  • 클라이언트는 전달받은 프레임들을 조립하여 완전한 형태의 데이터를 만듬
  • HTTP/1.1에서 요청과 응답은 하나의 메시지가 각 오브젝트의 요청과 응답을 담당했지만, HTTP/2에서는 하나의 스트림이 다수의 요청을 포함하고 이에 대한 다수의 응답 정보를 포함하는 구조로 바뀜
  • 스트림 방식을 사용함으로써 HTTP/1.1 버전보다 동시 요청 및 응답할 수 있는 오브젝트의 개수가 많아짐


  • 스트림의 유연한 구조 덕분에 서버에서 만들어지는 응답 프레임들이 요청 순서에 상관없이 만들어진 순서대로 클라이언트에게 전달될 수 있음
  • 즉 HTTP/2에서는 하나의 TCP 연결을 통해 다수의 클라이언트 요청과 서버 응답이 비동기 방식으로 이루어지는 멀티플렉싱이 사용되어 HTTP/1.1의 HOL 문제가 해결됨

멀티플렉싱

  • 멀티플렉싱은 HTTP/1.1의 파이프라이닝 기능을 개선한 것
  • 파이프라이닝은 선입 선출 방식이라 먼저 요청된 콘텐츠가 완전히 전달되어 완료될 때까지 다음 콘텐츠들은 대기 상태로 있어야 함
  • 멀티플렉싱은 하나의 TCP 연결상에서 다수의 클라이언트 요청과 서버의 응답이 비동기 방식으로 이루어지는 기술임
  • 멀티플렉싱은 스트림을 사용하여 웹 서버에서 나중에 요청받았더라도, 전달할 수 있는 경우 클라이언트에게 먼저 전달하는 구조임
  • 따라서 크기가 크거나 처리가 오래 걸리는 콘텐츠를 전달할 때 발생하는 병목 현상을 피할 수 있게 됨

헤더 압축

  • HTTP/1.1에서는 헤더를 통해 결정된 알고리즘으로 페이로드만 서버에서 압축하여 클라이언트에서 전달받았고, 헤더는 압축 없이 원래 크기로 전달받음
  • 헤더는 결국 클라이언트와 서버가 자신의 정보를 주고받는 값인데 모든 웹 콘텐츠를 요청하고 받을 때마다 같은 정보 값들을 의미 없이 반복해서 주고받는 구조적인 문제도 있었음
  • HTTP/2는 클라이언트와 서버 사이에 가상 테이블을 만들어서 동일하고 중복되는 헤더 값들을 테이블에 저장하고 참고하는 방식을 사용해 중복 전달을 제거함
  • 가상 테이블은 정적 테이블과 동적 테이블로 나눌 수 있음
    • 정적 테이블에는 미리 정의된 자주 사용되는 헤더 필드를 저장함
    • 동적 테이블은 클라이언트와 서버가 통신하며 주고받는 값들을 업데이트함
  • 각 테이블에는 숫자로 표기된 인덱스 번호가 있는데, 동일한 값을 전달할 때는 중복 값을 보내는 대신 그 값을 가진 인덱스 번호로 대체하여 보냄


  • HTTP/2는 헤더 압축 알고리즘인 HPACK을 사용해 허프만 알고리즘 방식으로 헤더를 압축하여 좀 더 경량의 데이터를 주고받을 수 있게 됨
  • 허프만 알고리즘은 자주 등장하는 값과 그렇지 않은 값마다 코드 값을 다르게 부여하는 알고리즘임

서버 푸시

  • HTTP/2에는 클라이언트의 요청이 없어도 서버가 여러 응답을 알아서 보내는 서버 푸시 기능이 추가됨
  • 클라이언트가 특정 콘텐츠를 요청하면 서버는 이후 추가될 요청을 미리 예상하고 요청 없이도 응답한다는 의미임
  • 서버 푸시 대상은 웹 서버 관리자나 개발자가 미리 정할 수 있음
  • 일반적으로 HTML을 호출한 후 해당 페이지가 호출하는 CSS 파일이나 자바스크립트, 이미지 파일 대상이 고정되어 있다면 HTTP/2를 지원하는 웹 서버에 서버 푸시 대상으로 미리 설정할 수 있음

HTTP/3의 최적화 기술

  • HTTP/3를 이해하려면 먼저 QUIC을 알아야함
  • QUIC는 구글이 개발한, OSI 레이어 중 네 번째 계층에 해당하는 전달 계층 프로토콜임

QUIC

  • QUIC는 Quick UDP Internet Connections를 의미함
  • QUIC은 UDP를 채택해 TCP의 성능을 개선하려는 기술임
  • 전달 속도 향상과 더불어 클라이언트와 서버의 연결 수를 최소화하고 대역폭을 예상해 패킷 혼잡을 피하는 것이 QUIC의 주요 특징임
  • QUIC은 이전에 클라이언트가 한 번이라도 접속했던 서버라면, 별도의 정보 교환 없이 바로 데이터를 보내는 기술을 소개함

HTTP/3의 등장 배경

  • TCP는 성능보다 기능에 초점을 두었으므로 멀티미디어 콘텐츠를 다양한 기기에 빠르게 전달해야 하는 상황에서 TCP의 한계를 극복하고 최적화하는 것이 많은 기업들의 도전 과제였음
  • 프레임을 사용한 멀티플렉싱은 HOL 문제를 해결했지만, 여진히 TCP 스택을 사용하였으므로 TCP 프로토콜 자체의 HOL을 완벽하게 해결하지는 못함
  • 구글과 HTTP/3를 담당하는 IETF 분과는 TCP의 높은 신뢰성과 UDP의 빠른 성능을 토대로 차기 버전의 연구를 계속하여 마침내 QUIC 기반의 HTTP/3을 고안함

HTTP/3의 특징

  • HTTP/3의 가장 큰 특징은 TCP/IP 기반 애플리케이션 레이어 프로토콜인 HTTP를 QUIC 위로 위치시켰다는 것임
  • 이를 'HTTP over QUIC', 줄여서 HQ라고 함
  • HTTP/3은 HTTP/2의 TCP HOL 문제만 개선한 것이 아니라 HTTP/2의 모든 기능을 계승해 UDP의 빠른 성능, QUIC의 효율성, TLS 1.3의 보안성까지 모든 장점을 가짐
    • 기존 명칭은 HQframe, QPACK 등으로 변경됨

HTTP/3을 지원하는 제품군

  • HTTP/3를 사용하려면 HTTP/2와 마찬가지로 웹 브라우저와 웹 서버, 즉 클라이언트와 서버 모두 HTTP/3 프로토콜을 지원해야 함
  • LiteSpeed가 처음으로 HTTP/3 RFC의 내용에 따라 서버를 구현함
  • 같은 시기 페이스북은 클라이언트가 HTTP/3을 지원하도록 업데이트함
  • 페이스북의 또 다른 프로젝트인 mvfst 라이브러리는 IEFT QUIC을 구현한 것임
  • 엣지 브라우저도 2019년 10웗부터 HTTP/3를 지원하며 HTTP 클라이언트 도구인 curl도 적용함
  • Cloudflare와 구글은 Cloudflare의 CDN 상품에서 HTTP/3을 적용할 수 있는 옵션을 발표했고, 크롬 브라우저의 카나리아 버전에 HTTP/3을 적용하기 위해 공동으로 개발 및 테스트를 진행함
  • Nginx 또한 HTTP/3 구현체를 발표했으며 파이어폭스와 크롬 브라우저의 지원이 시작됨

새로운 프로토콜 적용 시 고려할 점

  • 새로운 IT 기술을 먼저 적용할 경우 대두되는 사안은 보안 취약점과 사례의 부족임
  • 또한 이미 HTTP/1.1이나 HTTP/2 기반 프론트엔드 최적화를 적용한 기업은 최적화 방안을 수정해야 함
  • 마지막으로 시장의 레퍼런스가 부족함

💭 Insights

HTTP HOL과 TCP HOL, 멀티 플렉싱, QUIC에 대한 정리

  • HTTP는 응용 계층 프로토콜로 요청과 응답이 존재한다
  • HTTP 레벨에서의 HOL은 하나의 응답이 손실되거나 지연되면 다음 응답들도 지연되는 것이다.


  • TCP는 전송 계층의 프로토콜로 데이터의 순서를 보장해주는 프로토콜이다.
  • TCP 레벨에서의 HOL은 TCP 스트림에서 하나의 손실된 패킷으로 인해 해당 패키지가 재전송 및 수신될 때까지 모든 스트림이 대기하게 된다.


  • HTTP/2의 스트림이 가진 유연한 구조 덕분에 요청과 응답을 독립된 단위가 아닌 스트림이라는 단위 하나로 묶을 수 있게 되었다.
  • 그 덕분에 서버에서 만들어지는 응답 프레임들이 요청 순서에 상관없이 만들어진 순서대로 클라이언트에 전달될 수 있게 되었다.
  • 따라서 먼저 온 요청에 대한 응답이 지연되어도 뒤 늦게 온 요청에 대한 응답들이 지연되지 않아도 된 것이다.
  • 하지만, HTTP/2는 TCP 프로토콜 위에서 동작한다.
  • TCP 통신에서 다수의 스트림을 하나의 TCP Conection으로 전송하게 된다면, 하나의 스트림에서 손실된 패킷이 발생하면 다른 스트림의 데이터도 손실된 패킷이 재전송 및 수신 될 때까지 대기하게 되는 것이다.
  • 따라서 이를 해결하기 위해 하나의 UDP Connection 안에서 스트림을 독립적으로 보는 QUIC가 등장해서, 하나의 스트림에서 손실된 패킷이 발생했을 때, 다른 스트림의 데이터 전달을 차단하지 않게 한 것이다.

사진 출처: https://bentist.tistory.com/36

results matching ""

    No results matching ""